Partage de ressources inter-origines (CORS) : Configuration et bonnes pratiques de sécurité

Dans le monde du développement web, la sécurité est primordiale. Un aspect essentiel de la sécurité web consiste à gérer la manière dont les pages web d'une origine peuvent accéder à des ressources d'une origine différente. C'est là qu'intervient le Partage de ressources inter-origines (CORS). Le CORS est une fonctionnalité de sécurité des navigateurs qui empêche les pages web d'effectuer des requêtes vers un domaine différent de celui qui a servi la page. Ce mécanisme est en place pour empêcher les sites web malveillants d'accéder à des données sensibles. Cet article fournit un guide complet sur le CORS, couvrant sa configuration, ses implications en matière de sécurité et ses bonnes pratiques.

Comprendre la politique de même origine (Same-Origin Policy)

Le CORS repose sur le fondement de la politique de même origine (Same-Origin Policy), un mécanisme de sécurité fondamental mis en œuvre par les navigateurs web. La politique de même origine empêche les pages web d'effectuer des requêtes vers un domaine différent de celui qui a servi la page. Deux URL sont considérées comme ayant la même origine si elles ont le même protocole (par ex., HTTP ou HTTPS), le même hôte (par ex., example.com) et le même port (par ex., 80 ou 443). Par exemple :

• http://example.com et http://example.com/path sont de la même origine.
• http://example.com et https://example.com sont d'origines différentes (protocoles différents).
• http://example.com et http://www.example.com sont d'origines différentes (hôtes différents).
• http://example.com:80 et http://example.com:8080 sont d'origines différentes (ports différents).

La politique de même origine est conçue pour prévenir les attaques de type Cross-Site Scripting (XSS), où un site web malveillant injecte des scripts dans un site web de confiance pour voler des données utilisateur ou effectuer des actions non autorisées. Sans la politique de même origine, un site web malveillant pourrait potentiellement accéder aux informations de votre compte bancaire si vous étiez connecté à votre portail bancaire en ligne dans un autre onglet.

Qu'est-ce que le Partage de ressources inter-origines (CORS) ?

Bien que la politique de même origine soit cruciale pour la sécurité, elle peut aussi être restrictive dans des scénarios légitimes où des sites web ont besoin d'accéder à des ressources provenant d'origines différentes. Par exemple, une application web hébergée sur example.com pourrait avoir besoin de récupérer des données depuis une API hébergée sur api.example.net. Le CORS fournit un mécanisme pour contourner la politique de même origine de manière contrôlée, permettant aux pages web de faire des requêtes inter-origines lorsqu'elles sont explicitement autorisées par le serveur.

Le CORS fonctionne en ajoutant des en-têtes HTTP à la réponse du serveur, indiquant quelles origines sont autorisées à accéder à la ressource. Le navigateur vérifie ensuite ces en-têtes et bloque la requête si l'origine de la page web effectuant la requête n'est pas autorisée.

Comment fonctionne le CORS : Les en-têtes HTTP

Le CORS s'appuie sur des en-têtes HTTP spécifiques pour faciliter les requêtes inter-origines. Voici les principaux en-têtes impliqués :

1. Origin (En-tête de requête)

L'en-tête Origin est envoyé par le navigateur dans les requêtes inter-origines. Il indique l'origine (protocole, hôte et port) de la page web qui effectue la requête. Par exemple :

            Origin: http://example.com
            

              
                Copy
              
            
          

2. Access-Control-Allow-Origin (En-tête de réponse)

L'en-tête Access-Control-Allow-Origin est l'en-tête le plus important du CORS. Il spécifie quelles origines sont autorisées à accéder à la ressource. Il peut avoir l'une des valeurs suivantes :

• Une origine spécifique : Par exemple, Access-Control-Allow-Origin: http://example.com n'autorise que les requêtes provenant de http://example.com.
• * (joker) : Access-Control-Allow-Origin: * autorise les requêtes de n'importe quelle origine. Cette option doit être utilisée avec prudence, car elle désactive de fait la politique de même origine pour cette ressource.

Exemple :

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

3. Access-Control-Allow-Methods (En-tête de réponse)

L'en-tête Access-Control-Allow-Methods spécifie les méthodes HTTP (par ex., GET, POST, PUT, DELETE) qui sont autorisées dans la requête inter-origine. Ceci est requis pour les requêtes de pré-vérification (expliquées ci-dessous).

Exemple :

            Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
            

              
                Copy
              
            
          

4. Access-Control-Allow-Headers (En-tête de réponse)

L'en-tête Access-Control-Allow-Headers spécifie les en-têtes HTTP qui sont autorisés dans la requête inter-origine. Ceci est également requis pour les requêtes de pré-vérification.

Exemple :

            Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With
            

              
                Copy
              
            
          

5. Access-Control-Allow-Credentials (En-tête de réponse)

L'en-tête Access-Control-Allow-Credentials spécifie si le navigateur doit inclure les informations d'identification (par ex., cookies, en-têtes d'autorisation) dans la requête inter-origine. Il peut avoir l'une des deux valeurs : true ou false. Si true est défini, l'en-tête Access-Control-Allow-Origin ne peut pas être défini sur *. Il doit s'agir d'une origine spécifique.

Exemple :

            Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

6. Access-Control-Max-Age (En-tête de réponse)

L'en-tête Access-Control-Max-Age spécifie le nombre de secondes pendant lesquelles le navigateur peut mettre en cache les résultats de la requête de pré-vérification. Cela peut améliorer les performances en réduisant le nombre de requêtes de pré-vérification.

Exemple :

            Access-Control-Max-Age: 3600
            

              
                Copy
              
            
          

Requêtes simples vs. requêtes de pré-vérification (Preflight)

Le CORS distingue deux types de requêtes inter-origines : les requêtes simples et les requêtes de pré-vérification.

Requêtes simples

Une requête simple est une requête qui répond aux critères suivants :

• La méthode est GET, HEAD, ou POST.
• Si la méthode est POST, l'en-tête Content-Type est l'un des suivants : application/x-www-form-urlencoded, multipart/form-data, ou text/plain.
• La requête ne définit aucun en-tête personnalisé (autre que ceux automatiquement définis par le navigateur).

Pour les requêtes simples, le navigateur envoie la requête directement au serveur. Le serveur répond ensuite avec les en-têtes CORS appropriés. Si l'origine est autorisée, le navigateur traite la réponse. Sinon, le navigateur bloque la réponse и lève une erreur.

Requêtes de pré-vérification (Preflight)

Une requête de pré-vérification est envoyée par le navigateur avant d'effectuer la véritable requête inter-origine si la requête ne répond pas aux critères d'une requête simple. Cela se produit généralement lorsque la requête utilise une méthode autre que GET, HEAD, ou POST, ou lorsque la requête définit des en-têtes personnalisés.

La requête de pré-vérification est une requête OPTIONS qui inclut les en-têtes suivants :

• Origin : L'origine de la page web qui effectue la requête.
• Access-Control-Request-Method : La méthode HTTP qui sera utilisée dans la requête réelle.
• Access-Control-Request-Headers : Une liste séparée par des virgules des en-têtes personnalisés qui seront utilisés dans la requête réelle.

Le serveur répond alors avec les en-têtes suivants :

• Access-Control-Allow-Origin : L'origine qui est autorisée à accéder à la ressource.
• Access-Control-Allow-Methods : Les méthodes HTTP qui sont autorisées dans la requête inter-origine.
• Access-Control-Allow-Headers : Les en-têtes HTTP qui sont autorisés dans la requête inter-origine.
• Access-Control-Max-Age : Le nombre de secondes pendant lesquelles le navigateur peut mettre en cache les résultats de la requête de pré-vérification.

Si le serveur répond avec les en-têtes CORS appropriés, le navigateur procède à la requête inter-origine réelle. Sinon, le navigateur bloque la requête et lève une erreur.

Exemples de configuration CORS

L'implémentation de CORS varie en fonction de la technologie côté serveur que vous utilisez. Voici quelques exemples pour des langages et frameworks côté serveur courants :

Node.js avec Express

L'utilisation du middleware cors est une approche courante pour configurer CORS dans Node.js avec Express :

            const express = require('express');
const cors = require('cors');
const app = express();

// Activer CORS pour toutes les origines
app.use(cors());

// Activer CORS pour une origine spécifique
// app.use(cors({ origin: 'http://example.com' }));

// Activer CORS avec des options
// app.use(cors({
//   origin: ['http://example.com', 'http://localhost:3000'],
//   methods: ['GET', 'POST', 'PUT', 'DELETE'],
//   allowedHeaders: ['Content-Type', 'Authorization'],
//   credentials: true
// }));

app.get('/api/data', (req, res) => {
  res.json({ message: 'Hello from the API!' });
});

app.listen(3001, () => {
  console.log('Server listening on port 3001');
});

            

              
                Copy
              
            
          

Python avec Flask

Vous pouvez utiliser l'extension Flask-CORS pour configurer CORS dans Flask :

            from flask import Flask
from flask_cors import CORS

app = Flask(__name__)

# Activer CORS pour toutes les origines
CORS(app)

# Activer CORS pour des origines spécifiques
# CORS(app, origins=['http://example.com', 'http://localhost:3000'])

@app.route('/api/data')
def get_data():
    return {'message': 'Hello from the API!'}

if __name__ == '__main__':
    app.run(port=3001)

            

              
                Copy
              
            
          

Java avec Spring Boot

Spring Boot offre plusieurs façons de configurer CORS. Une approche consiste à utiliser l'annotation @CrossOrigin :

            import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@CrossOrigin(origins = "http://example.com") // Origine spécifique
public class ApiController {

    @GetMapping("/api/data")
    public String getData() {
        return "Hello from the API!";
    }
}

// Configuration CORS globale (avec WebMvcConfigurer) :

// @Configuration
// public class CorsConfig implements WebMvcConfigurer {

//     @Override
//     public void addCorsMappings(CorsRegistry registry) {
//         registry.addMapping("/**")
//                 .allowedOrigins("http://example.com", "http://localhost:3000")
//                 .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
//                 .allowedHeaders("Content-Type", "Authorization")
//                 .allowCredentials(true)
//                 .maxAge(3600);
//     }
// }

            

              
                Copy
              
            
          

PHP

En PHP, vous pouvez définir les en-têtes CORS directement dans votre script :

            <?php
header("Access-Control-Allow-Origin: http://example.com");
header("Content-Type: application/json");

$data = array("message" => "Hello from the API!");
echo json_encode($data);
?>

            

              
                Copy
              
            
          

Considérations de sécurité pour CORS

Bien que CORS permette les requêtes inter-origines, il est crucial de comprendre les implications de sécurité et de l'implémenter correctement pour éviter les vulnérabilités.

1. Éviter d'utiliser Access-Control-Allow-Origin: * en production

L'utilisation du joker * dans l'en-tête Access-Control-Allow-Origin autorise les requêtes de n'importe quelle origine, désactivant de fait la politique de même origine pour cette ressource. Cela peut exposer votre API à des sites web malveillants qui pourraient potentiellement voler des données utilisateur ou effectuer des actions non autorisées. Au lieu de cela, spécifiez les origines exactes qui sont autorisées à accéder à la ressource. Par exemple, si votre application web est hébergée sur example.com et a besoin d'accéder à une API hébergée sur api.example.com, définissez l'en-tête sur Access-Control-Allow-Origin: http://example.com.

Exemple global : Imaginez une API de service financier définissant Access-Control-Allow-Origin: *. Un site web malveillant pourrait alors effectuer des requêtes vers cette API au nom d'un utilisateur connecté, pouvant potentiellement transférer des fonds à l'insu de l'utilisateur.

2. Valider l'en-tête Origin sur le serveur

Même si vous spécifiez une liste d'origines autorisées, il est important de valider l'en-tête Origin sur le serveur pour empêcher les attaquants de falsifier l'origine. Un attaquant pourrait potentiellement envoyer une requête avec un en-tête Origin falsifié pour contourner les vérifications CORS. Pour atténuer ce risque, comparez l'en-tête Origin avec une liste d'origines de confiance côté serveur. Si l'origine ne figure pas dans la liste, rejetez la requête.

Exemple global : Considérez une plateforme de commerce électronique. Un attaquant pourrait tenter d'imiter l'Origin d'une vitrine légitime pour accéder à des données clients sensibles depuis l'API de la plateforme.

3. Soyez prudent avec Access-Control-Allow-Credentials: true

Si vous définissez Access-Control-Allow-Credentials: true, l'en-tête Access-Control-Allow-Origin ne peut pas être défini sur *. Il doit s'agir d'une origine spécifique. C'est parce que l'autorisation des informations d'identification de n'importe quelle origine peut créer un risque de sécurité, car cela pourrait permettre à des sites web malveillants d'accéder aux données des utilisateurs s'ils parviennent à tromper un utilisateur pour qu'il visite leur site alors qu'il est également connecté au site web cible. Ce paramètre est important lors du traitement de cookies ou d'en-têtes d'autorisation.

Exemple global : Une plateforme de médias sociaux autorisant les requêtes inter-origines avec des informations d'identification nécessite une gestion prudente pour empêcher l'accès non autorisé aux comptes des utilisateurs.

4. Configurer correctement Access-Control-Allow-Methods et Access-Control-Allow-Headers

N'autorisez que les méthodes et en-têtes HTTP nécessaires pour les requêtes inter-origines. Si vous n'avez besoin que d'autoriser les requêtes GET et POST, n'autorisez pas PUT, DELETE, ou d'autres méthodes. De même, n'autorisez que les en-têtes spécifiques dont votre application a besoin. Des configurations trop permissives peuvent augmenter le risque d'attaques.

Exemple global : Un système CRM ne devrait exposer que les points de terminaison d'API et les en-têtes nécessaires aux intégrations tierces autorisées, minimisant ainsi la surface d'attaque.

5. Utiliser HTTPS pour une communication sécurisée

Utilisez toujours HTTPS pour une communication sécurisée entre le navigateur et le serveur. HTTPS chiffre les données transmises entre le navigateur et le serveur, empêchant l'écoute clandestine et les attaques de l'homme du milieu. L'utilisation de HTTP peut exposer des données sensibles aux attaquants, même si CORS est configuré correctly.

Exemple global : Les applications de santé doivent utiliser HTTPS pour protéger les données des patients transmises entre différentes origines.

6. Politique de sécurité du contenu (CSP)

Bien que non directement liée à CORS, la Politique de sécurité du contenu (CSP) est un autre mécanisme de sécurité important qui peut aider à prévenir les attaques XSS. La CSP vous permet de définir une liste blanche de sources à partir desquelles le navigateur est autorisé à charger des ressources. Cela peut aider à empêcher les attaquants d'injecter des scripts malveillants dans votre site web, même s'ils parviennent à contourner d'autres mesures de sécurité.

Exemple global : Les institutions financières emploient souvent des politiques CSP strictes pour limiter les sources de contenu chargées sur leurs portails bancaires en ligne, réduisant ainsi le risque d'attaques XSS.

Problèmes courants avec CORS et dépannage

Les erreurs CORS peuvent être frustrantes à déboguer. Voici quelques problèmes courants et comment les résoudre :

1. "Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée."

C'est l'erreur CORS la plus courante. Elle indique que le serveur ne renvoie pas l'en-tête Access-Control-Allow-Origin dans sa réponse. Assurez-vous que le serveur est configuré pour envoyer les bons en-têtes CORS pour l'origine de la page web qui effectue la requête. Vérifiez votre code côté serveur et vos fichiers de configuration.

2. "La réponse à la requête de pré-vérification ne passe pas le contrôle d'accès : Elle n'a pas de statut HTTP ok."

Cette erreur indique que la requête de pré-vérification a échoué. Cela peut se produire si le serveur ne répond pas aux requêtes OPTIONS ou si le serveur renvoie un code de statut d'erreur (par ex., 404, 500) en réponse à la requête de pré-vérification. Assurez-vous que votre serveur est configuré pour gérer les requêtes OPTIONS et qu'il renvoie un code de statut 200 OK.

3. "La réponse à la requête de pré-vérification ne passe pas le contrôle d'accès : La valeur de l'en-tête 'Access-Control-Allow-Origin' dans la réponse ne doit pas être le joker '*' lorsque le mode des informations d'identification de la requête est 'include'."

Cette erreur se produit lorsque vous essayez d'envoyer des informations d'identification (par ex., des cookies) dans une requête inter-origine et que l'en-tête Access-Control-Allow-Origin est défini sur *. Comme mentionné précédemment, vous ne pouvez pas utiliser le joker * lors de l'envoi d'informations d'identification. Vous devez spécifier l'origine exacte qui est autorisée à accéder à la ressource.

4. Mise en cache du navigateur

Les navigateurs peuvent mettre en cache les réponses CORS, ce qui peut entraîner un comportement inattendu si la configuration CORS change. Pour éviter les problèmes de mise en cache, définissez l'en-tête Cache-Control dans la réponse sur no-cache, no-store, ou max-age=0. Vous pouvez également utiliser l'en-tête Access-Control-Max-Age pour contrôler la durée de mise en cache des résultats de la requête de pré-vérification par le navigateur.

Alternatives à CORS

Bien que CORS soit la méthode standard pour activer les requêtes inter-origines, il existe des alternatives que vous pouvez envisager dans certains scénarios :

1. JSON avec remplissage (JSONP)

JSONP est une technique qui utilise la balise <script> pour contourner la politique de même origine. JSONP fonctionne en enveloppant les données JSON dans un appel de fonction JavaScript. Le navigateur exécute ensuite la fonction JavaScript, en passant les données JSON en argument. JSONP est plus simple à mettre en œuvre que CORS, mais il a quelques limitations. Il ne prend en charge que les requêtes GET, et il est moins sécurisé que CORS.

2. Proxy inverse

Un proxy inverse est un serveur qui se place devant votre serveur d'API et lui transmet les requêtes. Le proxy inverse peut être configuré pour ajouter les en-têtes CORS nécessaires à la réponse, cachant ainsi les requêtes inter-origines au navigateur. Cette approche peut être utile si vous n'avez pas le contrôle sur le serveur d'API ou si vous souhaitez simplifier la configuration CORS.

Conclusion

Le Partage de ressources inter-origines (CORS) est un mécanisme de sécurité crucial qui permet aux pages web d'accéder à des ressources provenant de différentes origines de manière contrôlée. Comprendre comment CORS fonctionne et l'implémenter correctement est essentiel pour créer des applications web sécurisées et fiables. En suivant les bonnes pratiques décrites dans cet article, vous pouvez gérer efficacement le CORS et protéger vos API contre les accès non autorisés.

N'oubliez pas de toujours donner la priorité à la sécurité lors de la configuration de CORS. Évitez d'utiliser des jokers, validez l'en-tête Origin, et utilisez HTTPS pour une communication sécurisée. En prenant ces précautions, vous pouvez vous assurer que vos applications web sont protégées contre les attaques inter-sites.

Ce guide complet fournit une base solide pour comprendre le CORS. Référez-vous toujours à la documentation officielle de votre technologie côté serveur spécifique pour les informations les plus à jour et les bonnes pratiques. Restez informé des menaces de sécurité émergentes et adaptez votre configuration CORS en conséquence.